A known technique for incremental software development is to put changes that need testing into a filesystem directory which is logically overlaid upon a pre-existing source code tree. Executable code can then be created from the resulting combination. The advantage of this technique is that many changes can be tested and verified without the need to rebuild the entire source code tree.
The existing technique provides adequate support for testing the effect of adding files or changing existing files, but is less helpful for testing the effect of file removal. To determine the effect of removing a file, it has been necessary for a software developer to actually remove the file from the source code tree that is used by the build system, and to rebuild the entire program. Unless the file is actually removed, a comprehensive test of the effect of file removal would need to take account of every explicit or implicit reference to that file. Implicit references by tools that will be used in the build process are difficult .for a tester to identify manually.
The above-described problem arises, for example, in a development environment that uses ‘sandboxes’. A ‘sandbox’ is a private program development environment for a developer—isolated from other sandboxes and isolated from other developers who may be concurrently changing other code modules. Code may be developed within a developer's isolated sandbox and then combined with a pre-existing set of computer program files. A build process can then be applied to this combination of source code elements to generate executable code. Each developer working within a sandbox may wish to test the effects of adding, changing and removing files before these updates are imposed on other developers.
Additional files and file changes that are coded within the sandbox can be overlaid on a set of backing files to enable testing, but it is more difficult to test the effects of removing a file. Although a developer could identify and list the files they wish to remove, there are likely to be a number of tools (compilers, assemblers, linkers, etc that are executed to build the program) that continue to implicitly reference a nominally “absent” file. It is not practical to adapt such tools to a build-system-specific way of determining which files should be treated as absent. Therefore, the conventional approach of physically removing files and then rebuilding the complete program is still used.
Although this problem reduces software development efficiency, there is an even greater need to fully test the effect of removing files within run-time data processing environments. A user of a set of computer programs may be running business-critical applications on an application-infrastructure product for which an upgrade becomes available. The user needs to be able to test the effect of upgrading their infrastructure before proceeding, to minimize the risk of losing availability of their critical applications. Because of the difficulty of identifying implicit file references, it is currently difficult to test the effects of file removal until the new program files are installed and the old files are actually removed from the run-time environment.